home *** CD-ROM | disk | FTP | other *** search
/ Hackers Underworld 2: Forbidden Knowledge / Hackers Underworld 2: Forbidden Knowledge.iso / VIRUS / VDETECT.TXT < prev    next >
Internet Message Format  |  1990-09-27  |  14KB

  1. From: jmolini@nasamail.nasa.gov (JAMES E. MOLINI)
  2. Date: Wed, 4 Apr 90 14:03 PDT
  3. Message-Id: <LJJA-2875-5674@nasamail>
  4. To: virus-l@ibm1.cc.lehigh.edu
  5. Cc: rdavis@nasamail.nasa.gov, lsnapp@nasamail.nasa.gov
  6. Subject: Universal Virus Detector?
  7. X-Lines: 272
  8.  
  9. I am working with a colleague on defining a robust virus detection
  10. utility.  The paper below discusses an approach we are investigating.
  11. The work was undertaken as part of a research project sponsored by the
  12. National Aeronautics and Space Administration at the Johnson Space Center.
  13.  
  14. Please look it over and tell us what you think.  We would like to know what
  15. type of virus could be written to defeat this type of detector on a large
  16. scale.  I know it is a rather long document, but you might find it
  17. interesting.  Thanks in advance.
  18.  
  19.                    A Universal Virus Detection Model
  20.  
  21.  
  22.                      by Chris Ruhl and James Molini
  23.                         Computer Sciences Corp.
  24.                   Email: jmolini@nasamail.arc.nasa.gov
  25.  
  26. PREFACE
  27.  
  28. This paper attempts to define an abstract model which will support the
  29. construction of a Universal Virus Detector.  Although the restrictions
  30. imposed upon the model for 100% accuracy may be too severe to make such
  31. an implementation practical, it is quite feasible to achieve  near
  32. universal virus detection in a user friendly fashion.
  33.  
  34. This paper is distributed with the intent of discovering reasonable
  35. vulnerabilities in the concepts, or implementation.  Comments are
  36. therefore encouraged.  We have used an IBM PC Compatible running MS DOS
  37. 3.X as the candidate implementation platform for convenience.
  38.  
  39. The paper does not discuss virus identification, which is a separate
  40. issue from detection.  Although not "absolutely necessary," virus
  41. identification mechanisms dramatically reduce the time required to
  42. eradicate specific cases of virus infection.
  43.  
  44. If you have questions, or see a flaw in the process, please let us
  45. know.  We are building a virus detector, which could be placed into the
  46. public domain, that uses the techniques below to detect virus
  47. infections.  Our initial tests have shown encouraging results.
  48.  
  49. Please send comments/suggestions to Virus-L, or the authors at the
  50. Email address above.  Please do not request code samples, or testing
  51. opportunities until we announce availability of the utility.
  52.  
  53. Definitions
  54.  
  55. Before proceeding with our discussion, it is important to define
  56. terms.  The following definitions are taken (as faithfully as possible)
  57. from the most recent discussions about viruses on the various Email
  58. networks:
  59.  
  60. VIRUS - A self-replicating program that must attach itself in some way
  61. to an existing executable on the target computer system in order to
  62. propagate.  In doing so, no overt user action is required to further
  63. the replication process.
  64.  
  65. TROJAN HORSE - A non-replicating malicious program that misleads the
  66. user in order to cause him/her to execute it's malicious code.
  67. Although it is malicious code, it is often hidden inside another piece
  68. of (apparently innocuous) code in order to escape detection.  This type
  69. of program does not modify any existing executable files on the system.
  70.  
  71. WORM - A self-replicating program that does not attach itself to other
  72. executable code in order to propagate.  It relies upon some weakness in
  73. a multi-user system, or requires some sort of overt user action in
  74. order to operate.  The technical feasibility of worms on single user
  75. computer systems is debatable.
  76.  
  77. INFECTION - The act of modifying existing executable code in order to
  78. propagate a virus.
  79.  
  80. MASKING - The act of preventing discovery by intervening at some point
  81. in the scanning process.  Typically this effects an indication of a
  82. clean system, when, in fact, the environment under review has been
  83. modified.
  84.  
  85. Understanding the scope of the virus problem, it is possible to define
  86. a circumstance in which a Universal Virus Detector (UVD) may be
  87. successful.  We further scope the problem by NOT requiring that the UVD
  88. prevent an infection.  Instead it can identify an infection after it
  89. has occurred.  This principle is similar to the idea that smoke
  90. detectors are not responsible for preventing fires, although they may
  91. periodically work toward that end.  They are actually responsible only
  92. for responding to indications that a fire may be present and warning
  93. the user of impending danger.  UVD's must be scoped to a similar
  94. purpose for them to work.
  95.  
  96. With this in mind, let us begin by defining the physic of computer
  97. viruses:
  98.  
  99.  
  100.                        A Virus Propagation Model
  101.  
  102.  
  103.    Although a Virus is an abstraction (i.e. Program), the environment
  104. it attacks is not (i.e. IBM PC). Regardless of how creative the author
  105. is, he/she cannot change certain characteristics of the machine that
  106. the Virus inhabits.  In order to develop this model the following
  107. assumptions are made:
  108.  
  109.      a.) The user will begin the detection process (we have proposed a
  110.          CRC type routine) prior to infection.  By doing so, the user
  111.          has provided an uninfected baseline from which to judge future
  112.          states.  Although virus propagation may still be identifiable
  113.          on an infected machine, the level of detection for subsequent
  114.          states becomes indeterminate.
  115.  
  116.      b.) The user will avoid the introduction of self modifying code
  117.          into the system.  By doing so, he/she ensures that the target
  118.          system maintains a given state of integrity.
  119.  
  120.  
  121.  
  122. Given the assumptions above, we may now define the circumstances
  123. necessary to support a virus infection.  Without the adherence to the
  124. following rules, it is impossible to define a circumstance in which a
  125. virus can propagate.
  126.  
  127.   Rule #1: A Virus infection, or propagation occurs when an
  128.               executable file is altered.
  129.       Proof:
  130.       I)  An un-altered executable will not be infected since by
  131.           definition it is not altered.  Here we are assuming that the
  132.           original state of the machine is uninfected.
  133.  
  134.      II)  An unaltered piece of code that performs malicious acts is a
  135.           Trojan horse and thus, beyond the scope of this problem.
  136.  
  137.     III)  A non-executable file, whether altered, or not, cannot
  138.           further infect the system since by definition it is never
  139.           executed.  An altered non-executable is merely a damaged data
  140.           file.
  141.  
  142.       Thus: Only altered executables can further infect the system.
  143.  
  144.       Note: In certain cases, a new executable file can be added to the
  145.             system, but it still cannot infect the system, unless it is
  146.             called from a modified file in the system, (violating I
  147.             above) or unless the user intervenes, in which case the
  148.             program is not a virus, but a worm, or Trojan Horse.
  149.  
  150.    Rule #2:   Assuming that the detection mechanism is sufficiently
  151.               robust, the only possible way to avoid detection is to
  152.               mask the infection prior to having the detection results
  153.               presented to the user.
  154.  
  155.       Proof:
  156.       I)  An un-altered procedure cannot mask an infected file since
  157.           by definition its not altered to do so.  (Masking requires
  158.           foreknowledge of the code to be masked.  Such a masking
  159.           scenario would indicate a state of infection prior to
  160.           installation of the UVD violating a basic assumption that you
  161.           install it on a clean machine.)
  162.  
  163.       II) Masking requires some type of intervention in the file
  164.           read/result presentation process.  Here we assume that the
  165.           computation of the checksum is sufficiently robust that no 2
  166.           different pieces of code can generate the same result.
  167.           Therefore, since masking requires some type of modification
  168.           of data in the path from storage to user and since the only
  169.           2 feasible parts to that path are either the read, or the
  170.           delivery, any masking must be completed at one of the 2 ends
  171.           of the pipe.
  172.  
  173.       Thus: Only altered procedures can mask the infection of
  174. executables.
  175.  
  176.